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Sir: 

The Applicants (hereafter "the Appellants") hereby submit this Brief in support of his 
Appeal pursuant to 35 U.S.C. § 134 from a final decision by the Examiner as set forth in the 
Office Action of April 16, 2009. A Notice of Appeal was filed on October 16, 2009. Appellants 
submit a petition for a 3-month extension for the filing of this Brief with requisite fee. Appellants 
respectfully requests consideration of this Appeal by the Board of Patent Appeals and 
Interferences for allowance of the claims in the above-captioned patent application. 

An oral hearing is not desired. 
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I. REAL PARTY IN INTEREST 

Brixham Solutions LTD. is the real party in interest. 

II. RELATED APPEALS AND INTERFERENCES 

To the best of Appellant's knowledge, there are no appeals or interferences related to 
the present appeal, which will directly affect, be directly affected by, or have a bearing on the 
Board's decision. 

III. STATUS OF THE CLAIMS 

Claims 1-22 are the subject of the present appeal. 

Claims 1-22 stand finally rejected under 35 U.S.C. § 103(a) as being unpatentable over 
U.S. Patent No. 7,082,121 issued July 25, 2006 to Stammers, et al. (hereinafter "the Stammers 
patent") in view of U.S. Patent Application Publication No. 2004/0120502 published on June 24, 
2004 by Strathmeyer, et al. (hereinafter "the Strathmeyer reference") and further in view of U.S. 
Patent Publication No. 2003/0126195) published on July 3, 2003 by Reynolds, et al. (hereinafter 
"the Reynolds reference"). 

IV. STATUS OF AMENDMENTS 

The claims were not amended in response to the April 16, 2009 Final Office Action. 

V. SUMMARY OF THE CLAIMED SUBJECT MATTER 
Independent claim 1 claims: 

A method of establishing a connection between a first endpoint participating in a first protocol 
and a second endpoint participating in a second protocol including: 

establishing a virtual service endpoint participating in the first protocol on a network 
device that is connected to the first endpoint and the second endpoint, wherein the virtual 
service endpoint is configured to provide interworking between the first protocol and the second 
protocol; and 

forwarding to the second endpoint communication directed from the first endpoint to the 
virtual service endpoint using a forwarding table that includes: 

a mapping from a first interface associated with the first protocol to a first virtual 
interface; 

a mapping from the first virtual interface to a second virtual interface; and 
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a mapping from the second virtual interface to a second interface associated with 
the second protocol. 

The subject matter of the current specification relates to method of establishing a Virtual 
Service Endpoint (VSE) in the "middle" of a switch, which may participate in both a first protocol 
by connecting to a first interface/service endpoint and a second protocol by connecting to a 
second interface/service endpoint, and which may facilitate setting up a forwarding table to 
cross connect between the first interface/service endpoint and the second interface/service 
endpoint. The Virtual Service Endpoint may be a one-to-one correspondent to a cross-connect 
over the switch. The Virtual Service Endpoint may be designed as an internal mechanism in the 
network switch, not to be exposed to or accessible from the outside world. Exemplary methods 
are discussed throughout the specification and figures. 

Claim 1 relates to a method of establishing a connection between a first endpoint 
participating in a first protocol and a second endpoint participating in a second protocol, wherein 
the first limitation of claim 1 discloses establishing a virtual service endpoint participating in the 
first protocol on a network device that is connected to the first endpoint and the second 
endpoint, wherein the virtual service endpoint is configured to provide interworking between the 
first protocol and the second protocol. This limitation describes how the virtual service endpoint 
is configured in relation to the first protocol and the second protocol. ( Detailed Description , 
page 10, line 15 through page11, line 19 (and in numerous other locations in the specification) 
and shown in, but not limited to, FIGs. 3A and 3B. 

The second limitation of claim 1 discloses forwarding to the second endpoint 
communication directed from the first endpoint to the virtual service endpoint using a forwarding 
table that includes a mapping from a first interface associated with the first protocol to a first 
virtual interface; a mapping from the first virtual interface to a second virtual interface; and a 
mapping from the second virtual interface to a second interface associated with the second 
protocol. This limitation describes a mechanism by which the virtual service endpoint can 
present any protocol-specific service endpoint recognizable by any protocol to allow 
communication between any two disparate networks running different network protocols. 
( Detailed Description , page 12, line 18 through page 15, line 4, and shown in, but not limited to, 
FIGs. 4Aand 4B). 
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Independent claim 13 claims: 
A network device for establishing a connection between a first endpoint participating in a first 
protocol and a second endpoint participating in a second protocol including; 

a virtual service endpoint participating in the first protocol configured to: 

provide interworking between the first protocol and the second protocol; and 
forward to the second endpoint communication directed from the first endpoint to 
the virtual service endpoint using a forwarding table that includes: 

a mapping from a first interface associated with the first protocol to a first 
virtual interface; 

a mapping from the first virtual interface to a second virtual interface; and 
a mapping from the second virtual interface to a second interface 
associated with the second protocol; 
wherein the network device is connected to the first endpoint and the second endpoint. 

Independent claim 13 is directed to a network device which includes a virtual service 
endpoint that is configured to be able to perform the functional limitations as set forth in claim 1 . 
As the support for the specific structures and their functions, as claimed in independent claim 1, 
are contained in the same areas of the specification as the functional steps of claim 1 and 
related to the same system/process, the summary of these limitations will not be repeated, but 
merely incorporated herein by reference to the summary for claim 1 . 

Independent claim 14 claims: 
A computer program product for establishing a connection between a first endpoint participating 
in a first protocol and a second endpoint participating in a second protocol, the computer 
program product being embodied in a computer readable medium and comprising computer 
instructions for: 

establishing a virtual service endpoint participating in the first protocol on a network 
device that is connected to the first endpoint and the second endpoint, wherein the virtual 
service endpoint is configured to provide interworking between the first protocol and the second 
protocol; and 

forwarding to the second endpoint communication directed from the first endpoint to the 
virtual service endpoint using a forwarding table that includes: 



a mapping from a first interface associated with the first protocol to a first virtual 
interface; 

a mapping from the first virtual interface to a second virtual interface; and 
a mapping from the second virtual interface to a second interface associated with 
the second protocol. 



Independent claim 14 is directed to a computer program product which has two method 
limitations representing computer instructions. Both of the method limitations of claim 14 are 
essentially the same as both of the method limitations of independent claim 1 . Therefore, the 
summary of these limitations will not be repeated, but merely incorporated herein by reference 
to the summary for claim 1 . 



VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

Claims 1-22 stand finally rejected under 35 U.S.C. § 103(a) as being obvious over the 
Stammers patent in view of the Strathmeyer reference and further in view of the Reynolds 



VII. ARGUMENT 

REJECTION OF CLAIMS 1-22 UNDER 35 U.S.C. § 103(a) OVER THE 
STAMMERS PATENT IN VIEW OF THE STRATHMEYER REFERENCE AND 
FURTHER IN VIEW OF THE REYNOLDS REFERENCE IS IMPROPER, AS 
THE PATENT AND REFERENCES, EITHER ALONE OR IN COMBINATION 
DO NOT TEACH OR SUGGEST ALL OF THE CLAIM LIMITATIONS. THUS, 
A PRIMA FACIE CASE OF OBVIOUSNESS HAS NOT BEEN ESTABLISHED 

M.P.E.P. 706.02(j) sets forth the standard for a Section 103(a) rejection: 

To establish a prima facie case of obviousness, three basic criteria must 
be met. First, there must be some suggestion or motivation, either in the 
references themselves or in the knowledge generally available to one of 
ordinary skill in the art, to modify the reference or combine reference teachings. 
Second, there must be a reasonable expectation of success. Finally, the prior 
art reference (or references when combined) must teach or suggest all the 
claim limitations. The teaching or suggestion to make the claimed combination 
and the reasonable expectation of success must both be found in the prior art, 
and not based on applicant's disclosure. In re Vaeck, 947 F.2d 488, 20 
USPQ2d 1438 (Fed. Cir. 1991). 
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The Office has rejected claims 1-22 under 35 U.S.C. § 103(a) as being obvious over the 
Stammers patent in view of the Strathmeyer reference and further in view of the Reynolds 
reference. 

Independent claim 1 (from which claims 2-12 and 15-22 either directly or indirectly 
depend), independent claim 13, and independent claim 14 each contain the limitations of: 



a mapping from a first interface associated with the first protocol to 
a first virtual interface; 

a mapping from the first virtual interface to a second virtual 
interface; and 

a mapping from the second virtual interface to a second interface 
associated with the second protocol. 



The April 16, 2009 Final Office Action admits at page 3, lines 13-18 that the Stammers 
patent does not disclose these limitations. 



The April 16, 2009 Final Office Action then attempts to overcome the deficiency in the 
Stammers patent by relying on the Strathmeyer reference and cites to paragraph 0022, 0030- 
0031, 0056-0057, 0060, and 0064 of the Strathmeyer reference. These paragraphs have been 
reproduced below for the convenience of the Board. 

[0022] According to an embodiment, after receiving a call setup request, the call 
control proxy server may notify the ACD application of the receipt of the call 
setup request via a standard interface, such as a CTI link. The ACD application 
may control other subsystems to process the call, such as to route the call to a 
particular endpoint (such as an agent endpoint), to place the call in a queue to 
await an agent, and/or to apply media processing to the call. 

[0030] Each subsystem may comprise, for example, software or other logic 
provided on a node, where a node may comprise a computer, a server, switch, 
router, bridge, gateway, personal digital assistant, mobile device and so forth. 
Also, in other embodiments, two or more subsystems may be provided on a 
single node, where the subsystems on a single node may communicate via a 
software interfaces or other techniques, for example. Each subsystem may 
process information and may communicate with one or more of the other 
subsystems via a communications medium. A communications medium may 
include any medium capable of carrying information signals, such as twisted-pair 
wire, co-axial cable, fiber optics, radio frequencies, electronic, acoustic or optical 
signals, and so forth. As noted, subsystems may even communicate with each 
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other via a software interface or other technique. 

[0031] Each subsystem shown in FIG. 1 may be coupled to one or more other 
subsystems via a point-to-point link or via a network, such as the Internet, a 
Local Area Network (LAN) or the PSTN, as examples. Subsystems may also 
communicate through wires, buses or software interfaces, as additional 
examples. Each subsystem may communicate with other subsystems or devices 
by communicating information in the form of relatively short messages or packets 
in accordance with one or more communications protocols. A packet in this 
context may refer to a set of information of a limited length, with the length 
typically represented in terms of bits or bytes. An example of a packet length 
might be 1000 bytes. 

[0056] ACD Application 135 may be coupled to call control proxy server 130, for 
example, via a computer-telephony integration (CTI) link. In some instances, 
computer-telephony integration (CTI) may refer to the use of computers to 
manage telephone calls. A CTI link may be provided using an interface, such as, 
for example, a standards-based interface to allow computers to manage 
telephone calls using a common or known language. ACD application 135 may 
also be coupled to agent endpoints 145 via CTI link 178 and to one or more 
external applications via CTI link 180. ACD application 135 may coordinate the 
actions of the other subsystems to implement desired ACD call processing 
capabilities, such as queuing, routing and other call processing functions. 
According to an embodiment, ACD application 135 may dynamically generate a 
standard language media processing script, and then provide the script or a 
pointer or identifier (such as a URL) to the script to media server 140 for 
executing to apply media to a call. 

[0057] Throughout the entire process, the ACD application 135 may report the 
status of one or more (or even all) calls to external applications 180, to agent 
endpoints 145 (or to applications supporting agent endpoints 145) and other 
nodes, for example via the CTI links 178 and 180. ACD application 135 may also 
accept instructions from an external application (not shown) with respect to call 
control operations. This reporting and instructing may be performed according to 
an address space and call model that the ACD application 135 may expose to 
the external applications, which may be different than the actual name space and 
call model on which the underlying packet telephony network operates. For 
example, the ACD application may report calls delivered to agents according to 
their agent identifiers or user names. ACD application 135 may also report calls 
delivered to agents by the network address of the physical packet telephony 
endpoint at which the agent is located. 

[0060] At 205, various entities or subsystems, such as non-ACD endpoints, 
agent endpoints, media servers and call control proxy server may register their 
respective telephone addresses with Softswitch 125. A non-ACD endpoint may 
be an endpoint where further call routing or call distribution is typically not 
performed. Registration information may include the telephone address that is 
being registered and the network address (or other address) to which call control 
messages addressed to the telephone address should be forwarded. Softswitch 
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125 may generate a lookup table, a database, or other system for resolving or 
mapping between a registered telephone address and its corresponding network 
address. 



[0064] At 220 in FIG. 2, Softswitch 125 receives the call setup request for a 
packet-telephony call. Softswitch 125 may or may not detect that the call requires 
ACD functions, such as routing or queuing. Softswitch 125 may resolve the 
called telephone address, such as a telephone number, to a second address. In 
an embodiment, Softswitch 125 may resolve or map the called telephone number 
to a network or other address using a database lookup or other technique. In this 
example, based on a previous registration of this telephone address (telephone 
number), Softswitch 125 resolves or maps the called telephone address to a 
network address (such as an IP address or other address or resource identifier) 
of the call control proxy server 1 30. This is just one example to illustrate an 
operation of Softswitch 125 according to an embodiment. 

The April 16, 2009 Final Office Action asserts that the Strathmeyer reference teaches 
"receiving a call at a virtual endpointfor routing to another endpoint; standard-based interfaces 
for allowing calls to be managed; and node computers at the agents communicate with each 
other according to one or more communication protocol." 

Thus, according to Examiner, it would be obvious to one of ordinary skill in the art to 
implement or incorporate the Strathmeyer publication's first and second virtual interfaces 
associated with first and second protocols in the Stammer patent's method enabling agents to 
communicate with each other. 

The Appellants respectfully believe that the April 16, 2009 has leapt well beyond the 
teachings or suggestions of the Strathmeyer reference with such an assertion. The 
independent claims clearly require "a mapping from a first interface associated with the 
first protocol to a first virtual interface; a mapping from the first virtual interface to a 
second virtual interface; and a mapping from the second virtual interface to a second 
interface associated with the second protocol." The Strathmeyer publication does not teach 
these limitations. The Board is invited to review the paragraphs cited above. 

In order for a prima facie case of obviousness to be established, the Strathmeyer 
reference must teach or suggest all the claim limitations. The Strathmeyer reference does not. 

Furthermore, the April 16, 2009 Final Office Action simply cites seven (7) paragraphs in 
the Strathmeyer publication, then broadly asserts a teaching of the limitations. Such a non- 
specific rejection is not believed to be sufficient. The goal of examination is set forth in MPEP 
706 - "The goal of examination is to clearly articulate any rejection early in the prosecution 
process so that the applicant has the opportunity to provide evidence of patentability and 
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otherwise reply completely at the earliest opportunity." The Appellants respectfully believe that 
had the April 16, 2009 Final Office Action specifically matched the limitations to the Strathmeyer 
reference, it would have been clear that the Strathmeyer reference does not teach or suggest all 
of the limitations for which it is cited. 

The April 16, 2009 Final Office Action continues on page 4 with the statement that: 
"Stammers, in view of Strath, does not explicitly disclose: 
using a forwarding table that includes the above mappings" 

With that statement, the April 16, 2009 Final Office Action condemns its assertion that 
Strathmeyer teaches the mapping limitations, because without the forwarding tables with which 
the mappings are included within, how could the Strathmeyer reference teach or suggest the 
mappings as claimed? 

The April 16, 2009 Final Office Action attempts to overcome the deficiencies in the 
Stammer patent and the Strathmeyer reference by citing to the Reynolds reference. The 
April 16, 2009 Final Office Action cited paragraphs 0869 and 0871-0873. These paragraphs are 
reproduced below for the convenience of the Board. 

[0869] As explained above, to add a virtual connection, the user may select a 
port (e.g., 941a, FIG. 5v) and then select the "Add Virtual Connection" option 
from pull down menu 943 or the user may select a virtual ATM interface (e.g., 
947c, FIG. 5v) in Virtual ATM Interfaces tab 947 and then select Virtual 
Connections button 947d. After creating a virtual connection through Virtual 
Connection Wizard 952 (FIGS. 5w-5x), the user selects Finish button 953w. This 
causes the NMS client to place an "Add Virtual Connection" function call to the 
ATM node proxy. The function call includes the virtual ATM interface LID (stored 
in the GUI table), the corresponding ATM node PID and the parameters provided 
by the user through the Virtual Connection Wizard. The function call causes the 
NMS client to send JAVA RMI messages to the NMS server. The NMS server 
first searches local memory 987a for the ATM node LID. If a managed object 
including the ATM node LID is found, then the NMS server issues an "Add Virtual 
Connection" function call to the managed object including the virtual ATM 
interface LID and the parameters sent by the NMS client. If the ATM node LID is 
not found, then the NMS server uses the ATM node LID as a primary key into the 
configuration database to retrieve data corresponding to the ATM node. The 
NMS server then creates the ATM node logical managed object, stores it in local 
memory and then issues the "Add Virtual Connection" function call. The function 
call causes the NMS server to generate database access commands and send 
them to the configuration database within the selected network device. 

[0871] In addition to adding a row to Virtual Connection table 994, when a virtual 
connection is created one or more rows are also added to Virtual Link Table 995 
(FIG. 601) and Cross-Connection Table 996 (FIG. 60m). With regard to Virtual 
Link Table 995, the NMS server assigns a unique virtual link LID 995a (i.e., 
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primary key) to each endpoint in the virtual connection and inserts each endpoint 
LID within a row in the Virtual Link Table. The NMS server also enters data in 
each row representing attributes (e.g., A1-An) for the corresponding endpoint 
and the unique virtual connection LID 995b (i.e., foreign key for association) 
corresponding to the newly created virtual connection 994a (FIG. 60k). For a 
point-to-point connection there will be two end points-that is, two rows are added 
to the Virtual Link Table each including a unique endpoint LID 995a and the 
same virtual connection LID 995b (corresponding to the same virtual connection 
LID 994a, FIG. 60k). For a point to multipoint connection there will be one source 
endpoint and multiple destination endpoints— that is, more than two rows are 
added to the Virtual Link Table, one row corresponding to the source endpoint 
and one row corresponding to each destination endpoint, where each row 
includes a unique endpoint LID 995a and the same virtual connection LID 995b 
(corresponding to the same virtual connection LID 994a, FIG. 60k). 

[0872] Each row/record in Cross-Connection Table 60g, represents the 
relationship between the various endpoints and virtual connections. One row is 
created for each point-to-point connection while multiple rows are created for 
each point-to-multipoint connection. The NMS server assigns a unique cross- 
connection LID 996a (i.e., primary key) to each cross-connection and inserts 
each cross-connection LID within a row in the Cross-Connection Table. The NMS 
server also enters data in each row representing attributes (e.g., A1-An) for the 
corresponding cross-connection. The NMS server then enters two foreign keys 
for association: Virtual Link 1 LID 996b and Virtual Link 2 LID 996c. Within Virtual 
Link 1 LID 996b the NMS server inserts the source endpoint LID for the virtual 
connection. Within Virtual Link 2 LID 996c, the NMS server inserts a destination 
endpoint LID for the virtual connection. For each of these Virtual Link LIDs in 
Virtual a Link Table 995, the NMS server also inserts Cross-Connection LID 995c 
(corresponding to Cross-Connection LID 996a in Cross-Connection Table 996). 
Since a point-to-point connection includes only one destination endpoint, only 
one row in the Cross-Connection table is needed to fully represent the 
connection. One or more rows are necessary, however, to represent a point-to- 
multipoint connection. In each of the other rows, Virtual Link 1 LID 996b 
representing the source endpoint remains the same but in each row a different 
Virtual Link 2 LID 996c is added representing the various destination endpoints. 

[0873] Again, through the active query feature, the NMS database and NMS 
server are notified of the changes made to the Virtual Connection Table, Virtual 
Link Table and Cross-Connection Table in the configuration database. The NMS 
server creates configuration objects for each changed row and sends the 
configuration objects to the NMS client which updates the GUI tables to display 
the added virtual connection (e.g., 948a, FIG. 5z) in the Virtual Connections 
tab 948. 

The Appellants are unsure which components in the Reynolds reference disclose the 
claimed forwarding table, as the April 16, 2009 Final Office Action does not specify. The 
forwarding table, as set forth in the independent claims 1,13, and 14 is used to forward to the 
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second endpoint communication directed from the first endpoint to the virtual service endpoint. 
The Reynolds publication does not teach or suggest using a forwarding table to forward to the 
second endpoint communication directed from the first endpoint to the virtual service endpoint. 
The Appellants believe that a motivation of the April 16, 2009 Final Office Action to use a table 
described in the Stammer patent was gleaned only from the Appellants' disclosure and thus 
constitutes impermissible hindsight reasoning. 

Thus, as neither the Stammers patent, nor the Strathmeyer reference, nor the Reynolds 
reference, either alone or in combination, teach or suggest the limitations of the present claims, 
a prima facie case of obviousness has not been established. Therefore, the Appellants 
respectfully submit that claims 1-22 recite patentable subject matter. 

VIII. CLAIMS APPENDIX 

A copy of all claims on appeal is attached hereto as Appendix A. 

IX. EVIDENCE APPENDIX 

To the best of Appellant's knowledge, there is no extrinsic evidence relied upon by the 
Appellants in the appeal. 

X. RELATED PROCEEDINGS 

To the best of Appellant's knowledge, there are no decisions rendered by a court or the 
Board in any proceedings related to this case. 
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XI. CONCLUSION 

Appellants respectfully submit that all the pending claims in this patent application are 
patentable and request that the Board of Patent Appeals and Interferences overrule the 
Examiner and direct allowance of the rejected claims. 

This brief is submitted along with a fee for $540.00 to cover the appeal fee for one other 
than a small entity and a fee for $1 ,050.00 to cover a 3-month extension of time. 

Respectfully submitted, 

Date : March 16, 2010 by: /Ted A. Crawford/Reg. No. 50,610/ 

Ted A. Crawford Reg. No. 50,610 
Attorney for Appellants 
(503) 551-9442 
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APPENDIX A: CLAIMS ON APPEAL 



1 . A method of establishing a connection between a first endpoint participating in a first 
protocol and a second endpoint participating in a second protocol including: 

establishing a virtual service endpoint participating in the first protocol on a network 
device that is connected to the first endpoint and the second endpoint, wherein the virtual 
service endpoint is configured to provide interworking between the first protocol and the second 
protocol; and 

forwarding to the second endpoint communication directed from the first endpoint to the 
virtual service endpoint using a forwarding table that includes: 

a mapping from a first interface associated with the first protocol to a first virtual 
interface; 

a mapping from the first virtual interface to a second virtual interface; and 
a mapping from the second virtual interface to a second interface associated with 
the second protocol. 

2. A method as recited in claim 1, wherein the virtual service endpoint participates in the 
second protocol. 

3. A method as recited in claim 1, wherein the virtual service endpoint includes a first half 
virtual service endpoint and a second half virtual service endpoint and wherein the first half 
virtual service endpoint participates in the first protocol and wherein the second half virtual 
service endpoint participates in the second protocol. 

4. A method as recited in claim 1, wherein: 



14 



the first endpoint participates in a first protocol-specific network; 

the second endpoint participates in a second protocol-specific network; and 

the virtual service endpoint presents a first protocol-specific service endpoint to the first 

protocol-specific network, and presents a second protocol-specific service endpoint to the 

second protocol-specific network. 

5. A method as recited in claim 1 , wherein forwarding to the second endpoint includes 
using a forwarding table. 

6. A method as recited in claim 1, wherein forwarding to the second endpoint includes 
using a forwarding table that includes a real interface and a corresponding virtual interface. 

7. A method as recited in claim 1 , wherein forwarding to the second endpoint includes 
using a forwarding table that includes a real interface and a corresponding virtual interface for 
the first endpoint and a real interface and a corresponding virtual interface for the second 
endpoint. 

8. A method as recited in claim 1, wherein forwarding to the second endpoint includes: 
connecting the virtual service endpoint to the first endpoint; 

locating the virtual service endpoint in a forwarding table and finding the second 
endpoint; and 

connecting the data path between the two endpoints. 

9. A method as recited in claim 1 , wherein the virtual service endpoint includes a first half 
virtual service endpoint and a second half virtual service endpoint and wherein the first half 
virtual service endpoint participates in the first protocol and wherein the second half virtual 
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service endpoint participates in the second protocol, wherein forwarding to the second endpoint 
includes: 

establishing a connection between the first endpoint and the first half virtual service 
endpoint; 

establishing a connection between the second endpoint and the second half virtual 
service endpoint; 

and cross connecting the data path between the endpoints of the two connections. 

10. A method as recited in claim 1, wherein the virtual service endpoint maintains an 
identifier associated with an interface. 

11. A method as recited in claim 1 , wherein the first protocol is ATM. 

12. A method as recited in claim 1, wherein the network device is an edge switch or a 
gateway switch. 

13. A network device for establishing a connection between a first endpoint participating in a 
first protocol and a second endpoint participating in a second protocol including; 

a virtual service endpoint participating in the first protocol configured to: 

provide interworking between the first protocol and the second protocol; and 
forward to the second endpoint communication directed from the first endpoint to 
the virtual service endpoint using a forwarding table that includes: 

a mapping from a first interface associated with the first protocol to a first 
virtual interface; 

a mapping from the first virtual interface to a second virtual interface; and 
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a mapping from the second virtual interface to a second interface 
associated with the second protocol; 
wherein the network device is connected to the first endpoint and the second endpoint. 

14. A computer program product for establishing a connection between a first endpoint 
participating in a first protocol and a second endpoint participating in a second protocol, the 
computer program product being embodied in a computer readable medium and comprising 
computer instructions for: 

establishing a virtual service endpoint participating in the first protocol on a network 
device that is connected to the first endpoint and the second endpoint, wherein the virtual 
service endpoint is configured to provide interworking between the first protocol and the second 
protocol; and 

forwarding to the second endpoint communication directed from the first endpoint to the 
virtual service endpoint using a forwarding table that includes: 

a mapping from a first interface associated with the first protocol to a first virtual 
interface; 

a mapping from the first virtual interface to a second virtual interface; and 
a mapping from the second virtual interface to a second interface associated with 
the second protocol. 

15. A method as recited in claim 1, wherein the first virtual interface and the second virtual 
interface are identical. 

16. A method as recited in claim 1 , wherein the first endpoint is not aware of the second 
protocol and the second endpoint is not aware of the first protocol. 
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17. A method as recited in claim 1, wherein the virtual service endpoint appears as a first 
protocol specific service endpoint to the first protocol specific network. 

18. A method as recited in claim 17, wherein the virtual service endpoint appears as a 
second protocol specific service endpoint to the second protocol specific network. 

19. A method as recited in claim 1, wherein: 

the virtual service endpoint includes the first endpoint and the second endpoint; 

the first endpoint includes the first interface and the first virtual interface; and 

the second endpoint includes the second interface and the second virtual interface. 

20. A method as recited in claim 19, wherein the virtual service endpoint is located on the 
network device. 

21 . A method as recited in claim 1 , wherein the virtual service endpoint is located on the 
network device. 

22. A method as recited in claim 1, wherein: 

a third protocol specific network is connected to the network device; 

the first endpoint includes a mapping from a third interface associated with the first 
protocol to a third virtual interface; 

the second endpoint includes a mapping from the third virtual interface to a fourth 
interface associated with the third protocol. 
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